Utilising managing processors (MPs) is a common method to simplify complex control scenarios in a system on a chip (SoC) architecture. These managing processors are typically integrated within a SoC in order to assist a user (e.g. a programmer) to control a very large SoC.
Complex SoC architectures generally require hundreds of commands in order to function in a desired mode of operation. If one or more of the commands is/are incorrect, the complex SoC architecture may not function as desired. Therefore, managing processors are generally configured to allow a user to input a single command to the managing processor, which may then be expanded into an enormous control flow by the managing processor, or provide a platform for control processes running in the background of the SoC.
A problem with a use of such managing processors in SoC architectures is that they can remain in an ‘idle’ state for a considerable amount of time. This is particularly the case for configuration processors, which are active during a configuration phase, and then stay online, but in an idle state, in case ‘on the fly’ changes are required. Generally, these ‘on the fly’ changes are infrequent, and are usually spaced widely apart in time. As a result, there is typically a large amount of processing bandwidth that is not being used at any particular point in time. Thus far, this inefficiency of the managing processor has been addressed by creating specialized efficient processors (in addition to other trivial steps, such as introducing additional power management routines, etc.) or architectures that support the minimum number of possible processors.
Referring to FIG. 1, a known block diagram of a hardware management module 140 on board 115 is illustrated. The hardware management module 140 performs hardware management for a modular platform system (not shown).
The hardware management module 140 is implemented as a separate component from and/or residing within one or more of a board management controller 110, a processor 120, a chipset controller 130, a mezzanine card 145 or a memory 148. These components of board 115 are all coupled via communication channels 105. Communication channels 105 contain communication links such as fabric interfaces, in order to facilitate the forwarding of data and/or instructions between components within board 115 and/or to/from components remote to board 115, which are facilitated by communication links 112 and management bus 150.
In the case of FIG. 1, this known hardware management module provides a general purpose dedicated hardware to perform certain management tasks. However, such a known dedicated hardware management module is not able to perform additional functionality, and cannot be utilised for other tasks when in an idle state, without adding dedicated hardware to perform the required task.